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В статье представлен метод построения решателя задач интеллектуальной программной системы 
путем преобразования ранних ее моделей в его проектные модели, представления которых удобны и 
для человека и для программной обработки. Базированные на этом методе технология разработки и 
средства поддержки разработчиков обеспечат сопровождаемость такой системы. 
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Введение 


Автоматизация профессиональной деятельности, в том числе интеллектуальной, 
является распространенной сферой приложения усилий [Т-специалистов. Внедряемые 
взаимосвязанные комплексы программных, информационных и организационных сре- 
дств (например, интегрированный программный комплекс перинатального центра [1]) 
оптимизируют документооборот, формируют отчеты, ведут учет расходов, протоко- 
лируют работу персонала. Однако такие комплексы не имеют внутри себя средств 
поддержки принятия решений специалистов (в частности, пользователи перинатального 
центра нуждаются в системе поддержки принятия врачебных решений [1]). Успехи в 
автоматизации поддержки принятия решений при решении интеллектуальных задач 
связаны с созданием систем, основанных на знаниях. Но в доступных литературных 
источниках не представлены примеры таких систем, которые бы эксплуатировались 
и развивались в реальных условиях продолжительное время. 

В настоящее время от автоматизации интеллектуальной программной деятель- 
ности ожидают создания интегрированного интернет-комплекса средств поддержки 
принятия решения для требуемых задач и средств доступа к общим знаниям и другой 
информации. Интегрированный комплекс должен быть наращиваемым и сопровож- 
даемым [2]. Это требует объединения идей из области искусственного интеллекта с 
идеями из области современного программирования [3-5]. 

В известных трех фазах — определения, разработки, сопровождения програм- 
много обеспечения (ПО) [6] — успех последней зависит от результатов двух пред- 
шествующих. 

В фазе определения особая роль принадлежит деятельностям системного ана- 
лиза (СА), от которых зависит реализуемость всей ИПС. Фаза определения дает мно- 
жество моделей, от полноты которых зависит удовлетворенность пользователей ИПС, а 
фаза разработки — те, от которых зависит качество реализации и возможность со- 
провождения. В работе [2] показана возможность проектирования долгоживущей ин- 
теллектуальной программной системы (ИПС) на основе гипотезы о декларативном 
программировании. 

Цель представляемого исследования: разработка такого метода преобразования 
ранних моделей решателя интеллектуальной задачи в его декларативные проектные 
представления, на основе которого возможна автоматизация разработки долгожи- 
вущих систем, основанных на знаниях. 


Модели начальных стадий жизненного цикла, 
используемые при построении модели анализа требований 


Полный системный анализ, выполняемый в рамках автоматизации профессио- 
нальной деятельности, завершается построением множества моделей ИПС и ее ком- 
понентов, обеспечивающих ее сопровождаемость [7], среди них — онтология знаний 
предметной области, концептуальная архитектура автоматизирующей системы, 
математическая постановка каждой задачи, алгоритм решения. 

До формулирования задачи должны быть определены: термины действительности — 
«ненаблюдаемые неизвестные» (например, для медицинской диагностики — «диаг- 
ноз», «интервалы развития признака» [8], [9]), ограничения целостности ситуаций дейст- 
вительности (например, «Интервал, на котором наблюдается развитие некоторого 
признака, покрывает все моменты наблюдения этого признака» [8]), соглашения о 
связях действительности и знаний («Если заболевание входит в диагноз, то число 
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периодов развития этого заболевания у пациента совпадает с числом периодов его 
развития в базе знаний, а длительность каждого периода развития лежит между ниж- 
ней и верхней границами длительностями этого периода развития заболевания»). 

Постановка задачи содержит метод решения задачи. Пример метода диагнос- 
тики в медицине — «перебор всех возможных значений выходных данных (диагно- 
зов — отдельных заболеваний); для каждого заболевания выполняется построение всех 
возможных вариантов развития причинно-следственных связей (на основе информации 
из базы знаний, значений анатомо-физиологических особенностей пациента и значений 
произошедших с ним событий) и поиск среди них всех тех, которым соответствуют 
все наблюдаемые значения признаков пациента» [9]. 

На основе «метода решения задачи» и «связей знаний с действительностью» (час- 
ти онтологии знаний предметной области) аналитик или инженер знаний строит алгоритм 
решения (обычно онтологическим соглашениям о связях действительности и знаний 
сопоставляются отдельные подзадачи проверки выполнения соглашения). 

Пример. Алгоритм, установленный математиком или аналитиком для «постановки 
и объяснения диагноза» [9], в виде разбиения на подзадачи с учетом их вложенности, 
выглядит так: 

- Получить данные наблюдений пациента 
- Проверить гипотезу о том, что пациент здоров 
-- организовать Цикл по наблюдавшимся признакам 
--- проверить гипотезу о том, что все наблюдавшиеся значения выбранного 
признака могут иметь место у здорового пациента. 
--- запомнить значения признака, опровергающие гипотезу 
-- подытожить гипотезу о том, что пациент здоров; 
- организовать Цикл по заболеваниям 
-- проверить выполнение необходимого условия для текущего заболевания; 
-- проверить гипотезу о заболевании 
--- попытаться отвергнуть гипотезу о заболевании по «не-КК»-признаку 
--- организовать цикл по наблюдавшимся КК-признакам 
---- проверить возможность наблюдавшихся значений 
---- организовать цикл по вариантам проявления выбранного КК- 
признака 
----- сопоставить динамику знаний варианту  причинно- 
следственной связи (ПСС) 
----- добавить анализ этого варианта в объяснение 
---- подытожить результаты анализа всех вариантов в объяснении КК- 
признака 
-- подытожить результаты анализа всех признаков в объяснении заболевания; 
- выдать результат — множество диагнозов и их объяснение. 

Примечание. КК-признаком назван здесь признак, входящий в клиническую кар- 

тину заболевания, не-КК — соответственно - не входящий в нее. 


Модели требуемой функциональности решателя 


Анализ функциональности, поведения и обрабатываемой информации каждой 
подсистемы ИПС (в частности, специализированных решателей задач) тоже относится к 
фазе определения. Анализ требований, детализирующий функции, информацию и по- 
ведение подсистемы, проводится перед началом проектных работ (4е51епт®) каждой 
подсистемы ИПС. Для систем, основанных на декларативно-представленных знаниях, 
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наиболее важны первые две группы представлений. Обе они базируются на ранних 
моделях: функциональная модель — на математической постановке задачи и алгоритме, 
а модель обрабатываемой информации - на онтологии действительности. 

Модель функционального разбиения для решателя отдельной задачи зависит 
в большей мере от двух ранних моделей — предполагаемого алгоритма решения и поль- 
зовательских требований к решателю. Обе, как правило, существуют к концу СА. 
Наиболее традиционным представлением для алгоритма является блок-схема. Поль- 
зовательские функциональные требования могут быть выражены графовой моделью 
«вариантов использования», либо текстовым описанием пожеланий потенциального 
пользователя. 

Универсальным представлением для алгоритма решения задачи и модели функ- 
ционального разбиения задачи [6] может считаться иерархия подзадач. 

Модель разбиения на функции. Подзадача некоторого уровня (последовательная 
или с-ветвлением) разбивается на несколько различных мелких подзадач, к неко- 
торым из них может быть необходимо «цикличное обращение». Возможно и более 
детальное описание отношений между подзадачами, например, вместо «последователь- 
ная» — «строгий порядок» или «произвольный», вместо «с-ветвлением» — «по выбору 
пользователя» или «выбор в зависимости от вычисленных значений». Кроме того, 
подзадача может быть помечена как «необязательная», а нетерминальная подзадача 
может быть «абстрактной» [10]. Свойство отношения между подзадачами соседних 
уровней «цикличное обращение» может быть помечено как уточнение: «Обращается 
циклично по элементам конечного множества», — или — «итеративное обращение по- 
льзователя» [10]. 

Иерархическую модель подзадач (ИМп3З) в виде дерева разбиения естественно 
сохранять как иерархическую семантическую сеть (ИСС) - сеть с возможными по- 
лустепенями захода больше единицы. 

В процессе разбиения для элементов иерархии (подзадач) очередного уровня 
важно различать, состоят ли подзадачи в «простом» подчинении, в «цикличном» подчи- 
нении, будут «выбираться» или «необязательны». Структура ИСС может быть такой 
(здесь альтернативные представления элементов сети и множества элементов помечены 
спецификаторами ай и 5е1: 


задача { 
название: строка; 
структурность: -ай (последовательная; с-вариантами) 
—5е1 подзадача 
{подчиненность: -ай (в «простом» подчинении; 
в «цикличном» подчинении; 
«выбираемая по условию») 
название: строка; 
структурность: -ай (последовательная; с-вариантами) 
[-5е1 {—> подзадача}] 


1. 


Ожидаемая автоматизация поддержки разработчиков на этом этапе такова. По- 
скольку артефакт создается на основе моделей предметной области, задач и создавае- 
мой системы, то средства редактирования должны обеспечивать «контролируемое 
использование» содержимого этих артефактов: дать возможность просматривать, копи- 
ровать значения и помечать использованные элементы предшествующих моделей. 
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Доступная для просмотра и копирования фрагментов онтология задачи может 
быть доступна как множество предложений с возможностью размечать их {не рас- 
смотрено, использовано, не понадобилось} для последующего контроля полноты и 
прослеживаемости процесса разработки. Соответствующее предложение (соглашение о 
связях) после сопоставления ему подзадачи может помечаться как «использовано». 

Для разработчика желательна такая поддержка: автоматическое создание арте- 
факта «иерархия подзадач», как сеть с одной корневой вершиной-задачей с названием, 
совпадающим с названием в постановке задачи. 

Аналитик нуждается в средствах сохранения своей модели, поскольку эта модель 
станет «ключевой» (по ней будут производиться последующие, более «технические», 
представления решателя подсистемы). 

Модели связи функций решателя с данными. Традиционно анализ требований 
представляет связи функций с получаемыми и производимыми элементами инфор- 
мации. Для учета всех обрабатываемых данных подсистемы в модели каждое входное 
(или модифицируемое) данное следует различать как хранимое или интерактивно полу- 
чаемое от пользователя, либо промежуточное, формируемое в процессе решения 
«внутри» решателя и не требующее сохранения. Содержание и структура хранимых 
и получаемых от пользователя данных обычно являются частью онтологии действи- 
тельности, построенной на СА. 

Расширенная модель подзадач (РМПЗ) обогащает ИМПЗ связями с данными, таки- 
ми как «хранилища», в классической модели потоков данных [6]. 

Достаточная метаинформация для представления этой модели такова: 


задача { 
название: строка; 
структурность: -ай (последовательная; ОК с-вариантами) 
—5е1 подзадача 
{подчиненность: -ай (в «простом» подчинении, 
в «цикличном» подчинении, 
«выбираемая по условию»); 
название: строка; 
структурность: -ай (последовательная ОК с-вариантами) 
—5е1 входное данное;-ай хранимое, 
интерактивное, 
внутри решателя -5е1 {-> подзадача} }; 
—5е1 модифицируемое данное{-ай хранимое; 
интерактивное; 
внутри решателя -—5е! {-> подзадача} }; 


[-5е1 {—> подзадача} 11}; 
Пример представления некоторой задачи из «РМп3З» в виде сети: 


подзадача-2-1-1 [подзадача] 
Оценка гипотезы «признак в норме» [название]; 
в «цикличном» подчинении [подчиненность]; 
признак [параметр цикла] 
Дневник наблюдений. запись [входное данное] 
хранимое 
БЗ о Норме. признак [входное данное] 
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хранимое 
объяснение. гипотеза Здоров. опровергающий гипотезу признак 
[модифицируемое данное] 
хранимое 
подзадача-2-1-2 [подзадача]. 


Ожидаемая автоматизация поддержки разработчиков на этом этапе такова. 

Автоматизированная поддержка создания такого артефакта состоит в генерации 
узлов-подзадач со значениями атрибутов «название, структурность и подчиненность», 
скопированными из ИМпЗ, и возможности порождения необходимого количества 
элементов сети «входное данное» и «модифицируемое данное» для каждого узла- 
подзадачи. 


Построение архитектурных представлений решателя 


Фаза разработки включает в себя создание архитектурных представлений каждой 
подсистемы (специализированного решателя), создание прочих проектных представле- 
ний всех составных «частей» ИПС и собственно реализацию всех проектных решений. 
От архитектурных моделей зависит качество реализации и возможность сопровож- 
дения [6], [11]. 

В процессе архитектурного проектирования относительно независимой подсис- 
темы (такой как решатель ИПС) акцентируют внимание, во-первых, на модульной 
декомпозиции и распределении функциональности между этими модулями (ипи$, 
«единицами»), а во-вторых, на моделировании управления — определении взаимо- 
действия между ними [6]. 

Программными единицами (ПЕ), в зависимости от подхода к реализации, могут 
становиться процедурные единицы, объекты/классы, агенты или другие единицы. 
Построение специализированного решателя с помощью архитектуры вызова-возвра- 
та [6] (когда каждая ПЕ обращается к некоторой другой ПЕ — функции или процеду- 
ре, или операции класса объектов — путем ее вызова с ожиданием возврата управления) 
может быть осуществлено известными методами [6]. 

В этом случае необходимо дополнительно обеспечить возможность обращаться 
из ПЕ к элементам ИСС, хранящим знания, данные и формируемое объяснение. 

Другой подход — построение специализированного решателя, работающего со 
знаниями и данными в виде ИСС, в архитектуре с двумя типами ПЕ. Один тип - ак- 
тивные, относительно самостоятельные активные единицы, сообщающиеся друг с дру- 
гом посредством сообщений (назовем их агентами [4]), второй тип — операции над 
классами семантических сетей (по аналогии с операциями над АТД - абстрактными 
типами данных). 

Для такой архитектуры в соответствии с моделями задач определяется сначала 
модель необходимых ПЕ-агентов, затем моделируются взаимодействия ПЕ друг с 
другом, далее дополняется необходимыми ПЕ-операциями. 

Модель всех требуемых ПЕ. В процессе распределения функциональности, 
представленной в ИМпЗ, по основным ПЕ принимается решение по количеству еди- 
ниц, а связь по управлению только «намечается», т.е. указывается, как единицы друг 
другу «делегируют часть работы»: агент привлекает другого агента к сотрудничеству. 

Агентов (или блоков агентов) должно быть предложено столько, чтобы ско- 
ординировать и выполнить имеющиеся подфункции. 
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В случае выбора вышеобозначенного «агентного подхода» метатеория модели 
всех требуемых ПЕ, представляемой «иерархически», такова: 


сеть агентов { 
Корневой агент [строка] 
— 51 сотрудничество {имя агента-сотрудника [строка{ 
тип агента [управл, обрабат, группирующий] 
= 5етит -> сотрудничество} 1}; 


Такая сеть агентов показывает, в «услугах» какой ПЕ нуждается каждая ПЕ 
решателя. 

Ожидаемая автоматизация поддержки разработчиков на этом этапе такова. Про- 
цесс распределения функциональности между ПЕ в большей мере рутинный, чем 
творческий, и пригоден для автоматизированной продержки. 

Поскольку артефакт создается на основе модели подзадач, то средства редак- 
тирования должны обеспечивать возможность сопоставить подзадачам из функцио- 
нальной модели программные единицы с теми же названиями и возможность 
редактирования названий. 

Метод: Основной задаче сопоставляется корневой агент; «композитным» зада- 
чам (узлам модели с ненулевой полустепенью исхода) могут быть сопоставлены агенты 
с двумя блоками, конечным подзадачам (в «листовых» узлах) — обрабатывающие ПЕ. 
Для оптимизации числа ПЕ «листовые» подзадачи могут быть реализованы в ПЕ, 
соответствующих верхним уровням по усмотрению проектировщика. 

Пример. Сеть ПЕ (блоков агентов) может быть такой: 


постановка и объяснение диагноза [корневой агент] 
формирование объяснения [имя агента-сотрудника] 
{группирующий [тип агента] 
Оценить гипотезу здоров [имя агента-сотрудника] 
{группирующий [тип агента] 
Оценка гипотезы «признак в норме» [имя агента-сотрудника] 
обрабат [тип агента] 
сделать Вывод о здоровье [имя агента-сотрудника] 
обрабат [тип агента]} 
Оценка гипотезы имеется заболевание [имя агента-сотрудника] 
{группирующий [тип агента] 
Оценка гипотезы «признаки-не-КК в норме» 
[имя агента-сотрудника] 
Оценка гипотезы «КК- признак соотв заболеванию» 
[имя агента-сотрудника] 
{группирующий [тип агента] 
Проверка варианта КП [имя агента-сотрудника] 
обрабат [тип агента] 
Вывод о том, соответствует ли КК- признак заболеванию 
[имя агента-сотрудника] 
обрабат [тип агента] } 
сделать Вывод о заболевании [имя агента-сотрудника] 
обрабат [тип агента] }}. 
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Здесь ПЕ -— «Оценка гипотезы здоров» для выполнения своей работы должна 
проверить нормальность всех относящихся к делу признаков, т.е. обратиться к ПЕ 
«Оценка гипотезы "признак в норме"» для каждого из признаков. После того, как все при- 
знаки будут оценены, можно будет делать общий вывод о том, здоров ли пациент. 

Модель связей по управлению. Выбор способа взаимодействия агентов в про- 
цессе решения задачи является «более творческой» стадией по сравнению с построе- 
нием сети агентов. 

Для спецификации взаимодействия выбирается один из повторно используе- 
мых шаблонов сообщений, или проектируется новый шаблон. При выборе политики 
раздельного проектирования интерфейса и логики приложения модель может со- 
держать дополнительных агентов, обеспечивающих интерфейс с пользователем [4]. 

Метод построения модели связей по управлению по модели подзадач и сети 
агентов таков. Корневой агент запускается инициализирующим сообщением; агенты, 
сопоставленные подзадачам в некотором подчинении, реагируют на сообщение- 
задание, в случае «цикличного» подчинения такое сообщение имеет параметр, схо- 
жий с переменной цикла (ссылку на элемент конечного множества, хранимого в не- 
которой ИСС). Агент для подзадачи в «простом» подчинении, как правило, формирует 
ответное сообщение «обратная связь», а в «цикличном» подчинении — сообщение- 
СВЯЗЬ С ЦИКЛОМ. 

Наиболее удобным для восприятия человеком является представление взаи- 
мосвязей между ПЕ в виде графа, однако для поддержки единообразного хранения 
этой модели, методов доступа к ее элементам в процессе автоматизации ее построе- 
ния и использования требуется и вариант ИСС. Структура сети «управляющий граф» 
может быть такой: 
управляющий граф агентного решателя { 

Имя приложения [строка] 

= зе вершина-блокАгента { 
имя блока [строка] 
имя агента [строка] 
шаблон для запуска блока [$ шаблон]}; 

— зе дуга-сообщение { 
Вершина-отправитель [->имя блока] 
шаблон для следующего [$ шаблон]; 
управляющая метка [строка] 
Вершина-получатель [строка] }} 

Ожидаемая автоматизация поддержки разработчиков на этом этапе такова. 
Целесообразна генерация дуг с шаблонами инициализирующим и сообщение- 
задание, а для «обратных» дуг — выбор из двух вариантов: сообщений «обратная 
связь», сообщение-связь с циклом. При этом каждой для редактирования свойств 
каждой дуги необходима возможность смены шаблона сообщения. 

Пример. Промежуточный шаг процесса построения сети агентов и структуры 
их взаимодействия может выглядеть так. 

Подзадаче «Оценка гипотезы здоров» сопоставляется так называемой <груп- 
пирующий агент> «Оценить гипотезу здоров», это означает, что агент должен 
получить ответы на свои поручения, чтобы подытожить результат их выполнения 
(прежде, чем делать вывод, ему надо убедиться в том, что уже проверены все 
случаи). Он имеет более одного блока: блок реагирования на сообщение-задание (с 
параметрами «оценить норму», «ссылка на ИБ», ...) и блок реагирования на 
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сообщение-обратная связь или связь-с-циклом (с параметрами «ссылка на ИБ», «про- 
веренный случай/признак», оценка нормы для случая/признака). Последний блок поми- 
мо контроля полноты проверки также выполняет подзадачу «сделать заключение о 
признании здоровым», подчиненную рассматриваемой подзадаче. 

Дальнейшее проектное моделирование. Обусловленный предшествующими 
моделями выбор архитектуры решателя (рис. 4), в свою очередь повлияет на даль- 
нейшие модели, ведущие к реализации. Дальнейшее проектирование связано с добавле- 
нием в архитектурную модель информационных связей ПЕ, в частности через операции 
над хранимыми информационными ресурсами (ИР). Корневой агент, например, может 
проверить непустоту входных данных (в хранимых ИР), следовательно, требуется 
специфицировать ПЕ — операцию для выполнения такой проверки используемого ИР 
(в виде ИСС). Обрабатывающие агенты нуждаются в доступе к ИР, поэтому при 
архитектурном планировании должны быть предусмотрены все необходимые для 
этого операции. Агенты, производящие заключения и фиксирующие их в выходном 
ИР, нуждаются в операциях модификации ИСС. «Группирующий» агент должен убе- 
диться в том, что проверены все элементы множества, ему требуется доступ к элементам 
этого конечного множества (хранится как поддерево сем сети). Поэтому ожидается, 
что для обеспечения качества каждого решателя ИПС требуется построить и согла- 
совать такие его модели, как проект информационных связей агентов, спецификации 
и проекты интерфейсов каждого агента и проекты каждого хранимого ИР. 

Достаточность представляемых (проектируемых) наборов операций над ресурсами 
проверяется их присутствием в спецификациях множества агентов. Для решателей 
задач, работающих с ИСС, проект (архитектура) хранимого ИР -— описание его струк- 
туры и набор спецификаций операций, достаточных для манипулирования ими. Если 
имеет место повторное использование и АТД ранее разработан для некоторого ИР, 
то не исключена необходимость новой операции доступа к ИР такого типа, тогда фор- 
мируются спецификации на разработку. Проектные решения по информационным 
связям ПЕ могут быть представлены как расширение одной из построенных моделей, 
например, сети агентов. Расширение состоит в указании для каждого обрабатывающего 
агента-сотрудника множества обрабатываемых ИР и необходимых для такой обра- 
ботки операций. 

Структура сети для представления такой модели: 


Расширенная сеть ПЕ{ 
имя корневого агента [строка] 
{-5е1 хранимое данное {—5е! имя операции, } 
— 5е1 сотрудничество { 
имя агента-сотрудника [строка]; 
тип агента [управл, обрабат, группирующий]; 
-зетт хранимое данное { 
—5еЁ имя операции; } 
— 5етит -> сотрудничество} 


11}. 


Определив функцию каждой ПЕ и очертив ее интерфейс, проектировщики при- 
ступают к разработке (или поручают ответственным за дальнейшую разработку) каж- 
дого агента (и множества операций для каждого ИР) повторно-используемых единиц. 
Спецификации агента и последующие модели, составляющие конфигурацию каждой 
единицы, также представляются в соответствии с декларативно-агентным подходом. 
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Структура сети для представления спецификации агента содержит: 
имя агента, 
описание назначения агента, 

—5е1 вход-сообщение { 
описание функции агента 
шаблон вх сообщения, 
список параметров вх сообщения, 
—5е1 вых-сообщение { 
шаблон сообщения, 
список параметров}, 

—5еЁ входной ИР, 

—5е1 элемент информации из интерактивного источника, 

5 вых ИР}. 

Проекты каждого агента из архитектуры целесообразно строить параллельно с 
моделью связей по управлению. 

Пример. Агенту «Оценить гипотезу здоров» (его второму блоку) требуется опе- 
рация доступа к ИР «объяснение» «Запись в отчет, в норме ли признак». А чтобы 
сформировать задание для каждого признака, другому агенту надо обратиться к сети 
«ИБ» с операцией «Взять названия всех признаков». Агент «Оценить гипотезу «признак 
в норме» должен организовывать проверку всех значений, ему нужна операция «Взять 
все значения указанного признака», а также операция для обращения к указанной об- 
ласти значений — «взять все значения». Одной из операций доступа к ИР «база знаний о 
норме» может стать взять область нормальных значений признака («ссылка на БНорм», 
«признак»): множество значений или диапазон значений. Пример операции доступа 
к ИР «Объяснение»: добавить значение признака не-в-норме в гипотезу здоров (ука- 
занный признак, множество пар <значение, момент наблюдения>). 
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КЕЗОМЕ 


со 


Е.А. 5паеета 
Тре Мефоа о{ Сопягисйоп оГ[еШоепт! РгоЫМет 5о[уег’5 Реяеп 
Кергезетаноп5 гот ше Моае[5 ое Суче и1па[ $юазе$ 


ш оТуеп агасе фе арргоасб 10 4еуеюртеп оЁ ргоМет зо[уегз оР ап п\е|Цесваа1 
ргоэтат зузетз изше 4еуеюре@ Кпо\е4ее Базез, КерЁ ап ргосеззей ш Ме Югт оЁ 
зетапис пебмогК$, 15 оЙеге4. Ассог4те 0 Фе сопсерЕ о! то4егп пиеПесва1 зузета$ [2-5], 
Кпо\Ледее Базез Вауе ю Ъе, Ягзё, орегае4 Бу Ше ехрец, зесоп Ту, Бе зюоге4 ш сопсерша1 
шЮгппаноп гезойгсез, апа, пе ига, Бе ассеззе4 Бу ргостатаз. Т1$ пе\и арргоасН соп5155 ш 
гергезещайоп оЁ зо[уег ай еасн 4еуеортепЕ базе ш фе Югт оРШе дес!агайуе тоде|5. ЗисВ 
то4де!$ тод4е|5 Вауе 1ю Бе сеаг 10 1е 4еуеюрег ап4 аге сопуешепе Юг ргоэтат ассезз аз 
тисВ аз роз$1Ые ю и5е {Незе гезий$ аё Пе забзедиеп! 4еуеортепЕ ап тапепапсе. ТЬ1$ 
арргоасВ ргоу1ез сопзёгасйоп оЁзис зе{ оЁто4е!$ оРеасВ зо1уег \сВ пиши ез ехрепзез 
4агис 15 тапиепапсе. Агсйесвага| то4е|5 оРа зо1уег аге сопзгасед ул Ше тесаг Юг 
сопсерша! ше|-1еуе] агсЬиесвге оЁ ап вое зует. Ргоэтат ип $ УсН ш Ще соигзе оЁ 
ес15юп-таКкше изе зюге4 Кпо\Ледее ап Вап@е даа, а4Чгез$ ю Ше зетапис пебмотК$ 
уюте Фезе даа апа Кпо\Ледее.ТВе плео4 оЁ изе оЁ зоте то4е!$ Юг сопзйгасйоп оЁ Пе 
ЮПо\уше то4е[5 ап4 епзигте оЁргоэтат ассез$ 1ю аП {Везе то4е[ аге 1е Баз1$ Юг сгеайоп 
оЁ1юо[5 Юг деуеюртеп{ оЁопэ-Пуше пие|Песла1 ргоотат зузета5. 
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